The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
It is commonplace nowadays for two entities, such as a client application and a server application, to communicate with each other via a network or combination of networks such as the Internet. Often, the entities communicate with each other via one or more intermediary devices such as routers. The entities may communicate by sending data packets towards each other through one or more intervening networks. Routers, which are positioned between the entities, may intercept the data packets and forward the data packets towards the data packets' destinations. The entities typically remain unaware of the path taken by data packets through intervening networks and intermediary devices.
Two entities communicating with each other through one or more intervening networks typically do so using a suite of protocols. For example, the entities may use the Internet Protocol (IP), Transport Control Protocol (TCP), and Hypertext Transfer Protocol (HTTP) in combination to communicate with each other. Some of these protocols are connection-oriented. Connection-oriented protocols typically require connection-related parameters to be negotiated between entities to the connection before the connection is “opened.” Data can be sent through the connection only after these parameters have been negotiated and the connection has been opened.
Parameter negotiation is often achieved through a “handshake” phase of a protocol. A handshake phase usually requires a significant amount of communication between the entities. When encryption is involved, a handshake phase also may require a significant amount of processing by the entities. Due to this communication and processing overhead, the transmission of substantive content between the entities may be delayed significantly.
Intermediary devices sometimes include devices that take a relatively active role in the communications between two entities. For example, instead of merely forwarding intercepted data packets toward the data packets' destination, an intermediary device such as a firewall device might perform operations that require the accumulation of multiple data packets at the intermediary device prior to the sending of any of those data packets toward the destination. Due to some TCP characteristics, which are provided to enable TCP packet senders to verify that their TCP packets reach intended destinations, accumulating TCP packets at an intermediary device is more complicated than it might initially seem.
According to TCP, whenever a receiving entity receives a TCP packet, the receiving entity is supposed to respond to the sending entity, from which the TCP packet originated, with an acknowledgement that identifies the TCP packet. If the sending entity receives the acknowledgement, then the sending entity can rest assured that the receiving entity actually received the corresponding TCP packet. Alternatively, if the sending entity does not receive the acknowledgement within a reasonable period of time, then the sending entity may assume that the receiving entity did not receive the corresponding TCP packet, and the sending entity may re-send the corresponding TCP packet.
Under some circumstances, the sending entity will not send additional TCP packets until the sending entity has received acknowledgements for TCP packets that the sending entity has already sent. If a firewall device has been intercepting and accumulating TCP packets instead of forwarding the TCP packets to the intended receiving entity, then the intended receiving entity will not have been returning any acknowledgements to the sending entity. Due to the missing acknowledgments, the sending entity may re-send TCP packets that the firewall device has already accumulated instead of sending additional TCP packets that the firewall device needs to accumulate in order to determine whether to forward any of the accumulated TCP packets toward the intended receiving entity. The sending entity and the firewall device each end up waiting for the other to perform an action that the other will never perform.
This situation could be avoided by allowing the firewall device to behave as a “proxy” device. As a proxy device, the firewall device would send acknowledgements to the sending entity for each TCP packet that the firewall device received. The sending entity would receive the acknowledgements and continue to send TCP packets toward the firewall device. However, this would also necessitate the shifting, from the sending entity to the firewall device, of the burden of ensuring that the TCP packets reached the intended receiving entity; having received an acknowledgement for a particular TCP packet, the sending device will not re-send the particular TCP packet thereafter, even if the particular TCP packet never actually reaches the intended receiving entity. Thus, as a proxy device, the firewall device would need to receive acknowledgements from the receiving entity, and re-send any TCP packet for which no acknowledgement was received within a reasonable period of time.
To enable the firewall device to behave as a proxy device in this manner, two separate TCP connections need to be established: one between the sending entity and the proxy device, and another between the proxy device and the receiving entity. As is discussed above, establishing a TCP connection between two entities involves a time-consuming handshake phase. Thus, to enable the firewall device to behave as a proxy device, the sending entity engages in a first handshake phase with the firewall device, and then the firewall device engages in a second handshake phase with the receiving device. Because the negotiation of the second handshake phase depends on the negotiation of the first handshake phase, the two handshake phases cannot be performed concurrently. Until both handshake phases have been completed, TCP packets cannot flow between the sending entity and the receiving entity. The communication delay (latency) resulting from having to wait for two separate handshake phases to complete is both significant and undesirable.
This is not the only detrimental effect that may occur as a result of the proxy scheme discussed above. As is discussed above, a TCP connection between a sending entity and a proxy device may be opened before the proxy device attempts to open a TCP connection with the intended receiving entity. However, the receiving entity might not be available; the receiving entity might not respond to the proxy device's attempts to open a TCP connection with the receiving entity. Nevertheless, because the sending entity already successfully established a TCP connection between the sending entity and the proxy device, the sending entity may be left with the mistaken impression that a complete communication path to the receiving entity is available, when, in reality, the path ends at the proxy device. If the sending entity proceeds under this mistaken impression, the outcome may be unexpected and undesirable.
A connection technique that allows an intermediary device to accumulate multiple separate TCP packets before sending the TCP packets toward a destination, and that additionally avoids the delays produced as a result of a series of handshake phases, is needed.